Electromagnetic fault injection: towards a fault model on a 32-bit microcontroller 



Nicolas Moro*^-, Amine Dehbaoui^, Karine Hey demand, Bruno Robisson*, Emmanuelle Encrenaz^ 
* Commissariat a VEnergie Atomique et aux Energies Alternatives (CEA) 

Gardanne, France 
Email: {nicolas.moro, bruno. robisson} @ cea.fr 
^Ecole Nationale Superieure des Mines de Saint-Etienne (ENSM.SE) 
Gardanne, France 
Email: amine.dehbaoui@mines-stetienne.fr 
^Laboratoire d'Informatique de Paris 6 (LIP6) 
Sorbonne Universites, UPMC Univ Paris 06, UMR 7606, LIP6 
Paris, France 

Email: {nicolas.moro, karine. hey demann, emmanuelle. encrenaz}@ Iip6.fr 



Abstract — Injection of transient faults as a way to attack 
cryptographic implementations has been largely studied in 
the last decade. Several attacks that use electromagnetic fault 
injection against hardware or software architectures have 
already been presented. On microcontrollers, electromagnetic 
fault injection has mostly been seen as a way to skip assembly 
instructions or subroutine calls. However, to the best of our 
knowledge, no precise study about the impact of an electro- 
magnetic glitch fault injection on a microcontroller has been 
proposed yet. The aim of this paper is twofold: providing a 
more in-depth study of the effects of electromagnetic glitch fault 
injection on a state-of-the-art microcontroller and building an 
associated register-transfer level fault model. 

Keywords -microcontroller, timing fault, electromagnetic 
glitch, fault attack, fault model 

I. Introduction 

Physical attacks aim at breaking cryptosystems by gaining 
information from their implementation instead of using the- 
oretical weaknesses. Those attack schemes were introduced 
in the late 1990s. There are two main subclasses of physical 
attacks: passive and active ones. In passive attacks, an 
attacker uses the fact that some measurable data may leak 
information about manipulated secret data such as cryp- 
tographic keys. Physical quantities which can be used for 
passive attacks include execution time [1], electromagnetic 
radiations [2], power consumption [3] or light emissions [4]. 
In active attacks, an attacker modifies the circuit's behaviour 
in order to perform its attack scheme. Fault attacks are 
a subset of active attacks in which an attacker injects a 
transient fault in a circuit's computation. 

Faults attacks were introduced in 1997 by Boneh et al. [5]. 
They consist in modifying a circuit environment in order to 
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change its behaviour or to induce faults into its computations 
[6] [7] [8]. Many means are of common use to inject such 
faults, especially laser shots [9] [10] [11], overclocking [12] 
[13], chip underpowering [14] [15], temperature increase 
[16] or electromagnetic glitches [10] [17]. 

There are three main subclasses of fault attacks: algo- 
rithm modifications, safe error and differential fault analysis. 
Algorithm modifications aim at skipping [18] or replacing 
[13] some instructions executed by a microcontroller to 
circumvent its security features. Safe-error attacks aim at 
evaluating whether or not a fault injection has an impact 
on the output [19]. Differential fault analysis (DFA) aims 
at retrieving the keys used by an encryption algorithm by 
comparing correct ciphertext and faulty ciphertexts (i.e. ci- 
phertexts obtained from a faulted encryption). This technique 
was first introduced for public key encryption algorithms [5], 
and quicky extended to secret key algorithms [20]. 

From that time, many attack schemes have been proposed 
to attack various encryption algorithms. They all rely on 
an attacker's fault model which defines the type of faults 
the attacker can perform [21]. Thus, they require a high 
accuracy in the fault injection process. If the faults are not 
induced at the proper time in the algorithm, or affect the 
wrong bits, the entire attack process fails. As a consequence, 
the ability to precisely control the fault injection process is a 
key element in carrying out any fault attack. Common fault 
models include instruction skips [18], single bit faults or 
single word faults [22]. 

In this work, we report the use of electromagnetic pulses 
to induce faults into the computations of an up-to-date 
microcontroller. We also report a study of the local effect 
of electromagnetic pulses. Moreover, the underlying effects 
behind common fault models are not always clearly under- 
stood and may highly depend on the target architecture. As 
a consequence, this work finally aims at defining a precise 
fault model and providing an understanding of the faults an 
electromagnetic glitch can induce on an embedded program. 



The rest of this paper is organized as follows. Section II 
introduces our fault injection experimental setup and details 
the approach we use. Section III describes the influence of 
some experimental parameters on injected faults. Section 
IV details the effects of the injected faults on the program 
flow and data flow. Finally, the resulting register-transfer 
level fault model is presented in section V. Section VI gives 
details about some related research papers. 

II. Approach 

This section starts by describing our experimental setup 
choices in II-A. This experimental setup enables us to 
provide the results presented in section III which show the 
influence of the different experimental parameters. Then, we 
detail the approach we use to precisely characterize the faults 
we injected. This characterization method, which matches 
experimental results obtained from the microcontroller with 
simulation data, is detailed in II-B. 

A. Experimental setup 

1) Electromagnetic fault injection bench: The electro- 
magnetic glitch fault injection platform shown in Fig. 1 
is composed of a control computer, the target device, a 
motorized stage, a pulse generator, and a magnetic antenna. 
The target (described in II-A2) is mounted on the X Y 
Z motorized stage. The computer controls both the pulse 
generator (through a RS-232 link) and the target board 
(through a USB link). 



Control 
computer 




Figure 1: Electromagnetic fault injection bench 



The pulse generator is used to deliver voltage pulses to the 
magnetic coil. It has a constant rise and fall transition time 



of 2 ns. The amplitude range of the generated pulses extends 
from -200 V to 200 V, their width extends from 10 ns to 
200 ns. The magnetic antenna we use is composed of a few 
turns with a diameter of 1 mm. We use it in order to disturb 
a small part of the target device. This spatial accuracy is 
possible thanks to a high accuracy X Y Z stage. 

2) Target: The chosen target is an up-to-date 32-bit 
microcontroller designed in a CMOS 130 nm technology. 
It is based on the ARM Cortex-M3 processor [23]. Its 
operating frequency is set to 56 MHz. This microcontroller 
does not embed any cache memory. 

Choice of target: The target we use is a state-of-the- 
art microchip, based on a recent technology. ARM Cortex 
processors are already very widespread for both mainstream 
and secure microcontrollers. Although we did not choose a 
smartcard version of the microcontroller, this target embeds 
some basic security mechanisms against clock perturbations 
and voltage glitches. Moreover, several interrupt vectors 
have been defined which can handle some hardware faults 
and can be used for a basic fault detection. Hence, we can 
consider this target as reasonably secured against some of the 
most common low-cost fault injection means. However, this 
target does not embed any protective shield against reverse 
engineering or electromagnetic injection. Since this research 
aims at understanding the effects of fault injection on a 
recent microcontroller, we do not work on a highly-secure 
version of this microcontroller. 

Instruction set: Cortex-M3 processors run the ARM 
Thumb2 instruction set [24]. Thumb2 is actually the succes- 
sor to both ARM and Thumb instruction sets, and contains 
both 16-bit and 32-bit instructions. 

Hardware interrupts: Several fault exceptions can 
catch illegal memory accesses or illegal program be- 
haviour. Those fault exceptions are Hard Fault, Bus 
Fault, Usage Fault and Memory Management 
Fault. Each of these exceptions can be triggered for several 
subtypes of hardware faults. In the following experiments, 
every exception handler function executes an infinite loop. 

B. Experimental process 

Working with a microcontroller in such a black-box ap- 
proach requires to develop a specific experimental approach. 
This approach aims at enabling us to deduce the effects of 
faults by observing some internal data from the microcon- 
troller. This observation must be done with a non-invasive 
technique. Since a faults may have an impact on the program 
flow and since we need to access some accurate data such as 
registers or cycle count, the communication cannot be done 
with a serial link. We use the JTAG-equivalent non-instrusive 
SWD debug link to retrieve data from the microcontroller. 
Besides, we also use the hardware exceptions defined in 
II- A2 as a way to get some extra data about the injected 
faults. 



1) Microcontroller's internal state observation: The ex- 
perimental measurement process we use is the following: 

• Reset the microcontroller 

• Execute the target code 

• Send a pulse to the injection antenna 

• Interrupt the program execution 

• Harvest the microcontroller's internal data 

The following paragraphs detail the important elements 
of this experimental process. 

Trigger window: In order to have a correct view of 
the microcontroller's internal data, we have created an as- 
sembly subroutine containing some test instructions (which 
will be detailed in section III). For our experiments, the 
microcontroller sets a trigger signal for the electromagnetic 
injection. With this technique, we can target the executed 
program at the scale of a single instruction. By observing 
the microcontroller's clock during this trigger window, we 
can focus the injection on a single clock cycle. Besides, the 
pulse injection time is defined by reference to the beginning 
of the trigger signal temporal window. 

Watchpoint and program end: In this experimental 
process, the program normally stops because of a breakpoint 
set after the target code. This watchpoint is defined before 
popping the stack at the end of the assembly subroutine and 
after the trigger window. However, with our experimental 
setup and target code, two other scenarios may happen 
because of a fault: an unconditional jump and an infinite 
loop due to the triggering of an exception. These two 
scenarios modify the control flow, and the program may not 
reach the defined breakpoint. Moreover, the unconditional 
jump scenario makes the setting of breakpoints very hard. 
To handle these issues, our control computer stops the 
microcontroller after a fixed delay. 

Internal data: With the SWD debug link, the internal 
data we get from the microcontroller at a watchpoint for 
our experiments are: the general-purpose registers (rO to 
rl2), the stack pointer (rl3), the link register (rl4), the 
program counter (rl5), the program status register (xPSR), 
some chosen variables in memory and the number of clock 
cycles taken by our experiment. This number of clock cycles 
is counted from the beginning of the target subroutine. The 
xPSR register gives us information about the processor flags 
and the exceptions that may have been triggered. Since we 
only inject transient faults and since the watchpoint is set 
several clock cycles after our attack, we can reasonably 
assume that the debugging module embedded in the chip 
is not corrupted when recovering the internal data from the 
microcontroller. 

However, some internal data such as the instruction regis- 
ter cannot be accessed. When working at the scale of a single 
instruction, we may need to determine which instruction has 
been actually executed by the core. To get a list of suitable 
instructions, we need to rely on an exhaustive instruction 
simulation. 



2) Fault model simulation: We propose to use simulation 
to explain the effects of electromagnetic fault injection. Our 
approach aims at comparing the experimental faulty outputs 
with outputs from a fault model simulation. Thus, we can 
validate the interpretation of these effects by comparing the 
outputs with the internal data. This scheme is summarized 
in Fig. 2. 



Exhaustive instruction simulation 

(finds instructions which could 
enable to reach B' from A) 



Fault injection 



Initial state 



O 



Experimental fault 

(depends on the 
experimental parameters) 



Expected state 



Figure 2: Our approach to characterize the injected faults 

Simulations aim at finding output states which could be 
compatible with the output states we observed. In order to 
match simulations with measurements, we define a binary 
relation between experimental output states and simulated 
output states. 

Definition. One instruction replacement can explain an 

experimental measurement if the output states ([r0-rl2], 
xPSR) at the defined watchpoint are the same for the 
measurement and the simulation 

In the rest of this article, two classes of faults can be 
distinguished: faults on the data flow and faults on the 
program flow [22] . Faults that lead to the replacement of an 
instruction by another one are faults on the program flow. 
They may result in an algorithm modification, depending on 
the context and the replaced instruction. On the contrary, 
faults which only modify a piece of data without modifying 
an instruction are faults on the data flow. 

Nevertheless, this difference might not be clear for many 
cases since both fault classes may lead to very similar visible 
outputs. Thus, defining whether a resulting faulty output is a 
consequence of a fault on the data flow or the control flow 
is generally a tough task. Nevertheless, a single assembly 
instruction can only output a very limited set of data. As 
a consequence, it is possible to tell whether or not a faulty 
output is the consequence of a fault on the control flow. 
Thus, every faulty output which cannot be explained by an 
instruction replacement is considered to come from a fault 
on the data flow. 

The Thumb2 instruction set is composed of both 16-bit 
and 32-bit instructions. 16-bit instructions can be exhaus- 
tively tested. 32-bit instruction start with the prefixes 11101 
or 1111, which reduces the complexity of an exhaustive 
test. Moreover, the 32-bit part of the instruction set is mostly 
sparse, we can remove many branches in the search space. 

It should be noted that this simulation is performed on the 
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Figure 3: Impact of 



same binary as the one that is used for the fault injection 
experiments. To perform this simulation, we developed a 
specific program, based on the Keil UVSOCK library. Our 
simulation program is able to control the Keil |LtVision 
debugger during an execution on the Keil |LtVision simulator. 
It emulates faults on the control flow by replacing on the fly 
the target instruction. 

Obviously, many instruction replacements may be able to 
explain one single measurement. Nevertheless, being able to 
simulate instruction replacement will enable us to explain 
the effects we observed and then to define a fault model 
more clearly. To sum up, an exhaustive simulation over the 
instruction set is practical and can be performed in real 
conditions. Moreover, it enables to distinguish faults on the 
control flow from faults on the data flow. 

III. Experimental study of the injection 

PARAMETERS 

In this section, we provide a study of the influence of 
several experimental parameters on the final outputs. Since 
metastability phenomena appear, we first start by describing 
them in the following paragraph. 

A. Metastability phenomena 

Since electromagnetic glitch fault injection leads to timing 
faults [17], we obtained some metastability phenomena. For 
this experiment, the pulse's voltage was set to 190 V, the 
clock frequency was set to 56 MHz, the pulse's injection 
time was fixed to an arbitrary value, and the pulse width 
was set to 10 ns. The probe position was found by a trial- 
and-reset approach. The results for 10000 executions of 
our experimental process are presented in Table I, every 
observed output value is associated to its occurrence rate. 




ie probe's position 

They show a metastability phenomenon for a single load 
instruction from the Flash memory which correct loaded 
value is 0x12345678 since several values appear for the 
same fixed configuration of the experimental parameters. 

Table I: Metastability phenomenon for a single load instruc- 
tion 



Loaded value 


Occurrence rate 


1234 5678 (no fault) 


60.1% 


FFF4 5679 


27.4% 


FFFC 5679 


12.3% 


FFFC 567b 


0.1% 


FFFC 7679 


0.1% 



B. Study of the injection parameters 

In the case of an electromagnetic fault injection on a 
microcontroller, many experimental parameters can have an 
influence on the final outputs. The main parameters we 
can control in these experiments and which may have an 
influence are detailed in Table II. For all the following ex- 
periments except the one that studies the voltage's influence, 
the pulse voltage was set to 190 V. The pulse width was set 
to 10 ns, which is shorter than the 17 ns clock period (for a 
56 MHz clock frequency). In the following paragraphs, we 
detail the separate influence of some of these parameters. 



Table II: Experimental parameters 



Electromagnetic 
injection parameters 


- x-y-z position of the injection probe 

- Pulse injection time 

- Pulse characteristics (width, voltage) 


Microcontroller 
hardware parameters 


- Operating frequency 

- Power supply 


Microcontroller 
software parameters 


- Type of the executed instructions 

- Program memory (RAM or Flash) 



Memory manage fault 
Bus fault 
Usage fault 
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Figure 4: Influence of the pulse's injection time for an array sum whose expected result is OxFF 



1) Position of the injection probe over the package's 
surface: The X Y Z stage we use for our experiments 
enables us to vary the injection probe's position. Since 
varying the Z position of the antenna leads to a similar 
class of effects on the microcontroller than varying the 
pulse's voltage [25], we fix a position for Z and only study 
the influence of the X Y position. In this experiment, we 
change the X Y coordinates and the pulse's injection time. 
This experiment is performed at the scale of a single load 
instruction which loads the value 0x12345678 from the 
Flash memory into the register R8. This fault injection has 
been performed over a 20 ns time interval, by steps of 
200 ps. The probe browsed a 3 mm square over the circuit's 
die, by steps of 200 |Ltm. Fig. 3 shows the results for this 
experiment. 

The experiment shows that there are four kinds of outputs, 
depending on the probe position and the injection time : no 
fault on the loaded value, a crash of the microcontroller, 
the triggering of a Usage Fault exception, and a fault 
on the value in R8. Very few faults on the register RO 
were also observed. Except from R8 and RO, no other 
register was faulted in this experiment. Moreover, those two 
registers were never faulted together. Every faulty output 
we observed on R8 has a higher Hamming weight than the 
0x12345678 expected value. On Fig. 3, yellow areas led 
to a small increase in this Hamming weight and red areas 
led to a high increase. This experiment highlights the local 
effect of electromagnetic fault injection on a microcontroller, 
with different effects depending on the probe's position. 
Since very few probe positions can lead to a successful fault 
injection, this spatial cartography also helps us to find some 
suitable X Y Z configurations for the following experiments. 

2) Injection time: This experiment has been performed 
on the following test program for a fixed X Y Z position. 
This program uses a loop to sum the elements of an array 
that contains eight powers of two. array [i] contains 2\ 
At the end of the computation, the result stored at the address 
pointed by rO contains OxFF. This test program requires 
about 3.5 [is to complete. We performed this fault injection 
over this time interval, by steps of 200 ps. 



1 addition_loop : 

2 ldr r4 , [r2,rl, lsl #2] ; r4 = array[i] 

3 ldr r3 , [r0,#0] ; r3 = result 

4 add r3 , r4 ; r3 = r3 + r4 



5 str r3 , [r0,#0] ; result = r3 

6 add rl , rl , #1 ; rl = rl + 1 

7 cmp rl , #8 ; rl == 8 ? 
s bit addition_loop 

This test program enables us to perform an electro- 
magnetic fault injection on a sample made of different 
instructions. The results for this experiment are shown in 
Fig. 4. Three kinds of situations have been observed: 

• BusFault or UsageFault hardware interrupts 

• A fault on the output value 

• A normal behaviour with no fault 

Every fault we observed on the output value corresponds 
to an execution in which only one power of two has not been 
added. However, many faults could explain such results. That 
is why the precise effect of electromagnetic fault injection 
at the scale of a single instruction is studied precisely in 
section IV. 

3) Pulse characteristics: In the following paragraphs, we 
study the separate influence of the pulse parameters. For 
these paragraphs, a fixed position was set for the injection 
probe. This position had been found thanks to the spatial 
cartography presented in III-B1. 

Pulse width: The pulse width does have an influence 
on the outputs. According to Faraday's law of induction, the 
electromotive force induced in a loop (e.g. inside the power 
grid) corresponds to the time-derivative of the magnetic flux 
transmitted by the injection antenna. This magnetic flux is 
proportional to the current sent into the injection solenoid. 
Thus, the electromagnetic glitch that is transmitted to the 
circuit depends on the current's variations. We also observed 
that sending longer pulses reduces the stress applied to the 
circuit. 

Pulse voltage: To evaluate the influence of the pulse 
voltage, the test program has been set to a single LDR as- 
sembly instruction. LDR R_o , [ R_i , # o f f s et ] loads the 
value pointed by R_i with offset #of f set into the register 
R_o. For the test instruction, the register R_i pointed to a 
Flash memory address. To perform an analysis of the impact 
of the pulse's voltage, we needed to fix a suitable configura- 
tion for the other parameters. Those other parameters were 
set to some fixed values: we chose a configuration in which 
a fault occurs on the loaded value. For this experiment, 
the tested instruction was LDR R4, [PC, #44] . The inital 
value of R4 was 0x0 and PC+44 was a Flash memory 
address which contained 0x12345678. Since metastability 
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Figure 5: Hamming distance with 0x12345678 versus 
pulse's voltage 



phenomena appear, for this experiment we take into account 
the faulty output with the highest occurrence rate. Table III 
shows the value in R4 for different values of the pulse 
voltage. According to those results, increasing the pulse 
voltage increases the Hamming weight of the loaded value. 
This pattern is highlighted by Fig. 5, which shows the 
Hamming distance with the 0x12345678 expected value 
versus the pulse's voltage. The same kind of trend has been 
obtained for different values for the probe position and 
the injection time. However, it seems that only instructions 
which loads a value from the Flash memory can lead to this 
kind of set at 1 fault. Indeed, we did not manage to inject 
similar faults in case of a data transfer from the SRAM 
memory. 



Table III: Influence of the pulse's voltage 



Pulse voltage 


Loaded value 


Occurrence rate 


170 V 


1234 5678 (no fault) 


100% 


172 V 


1234 5678 (no fault) 


100% 


174 V 


9234 5678 


73% 


176 V 


FE34 5678 


30% 


178 V 


FFF4 5678 


53% 


180 V 


FFFD 5678 


50% 


182 V 


FFFF 7F78 


46% 


184 V 


FFFF FFFB 


40% 


186 V 


FFFF FFFF 


100% 


188 V 


FFFF FFFF 


100% 


190 V 


FFFF FFFF 


100% 



4) Type of the executed instructions: Our experiments 
highlighted a significant trend: we managed to inject faults 
on different types of instructions such as branch instruc- 
tions, ALU instructions or load- store instructions. However, 
load instructions from the Flash memory were significantly 
easier to fault. The microcontroller we use has a Harvard 



architecture. Every instruction fetch uses the instruction 
bus. Moreover, load instructions also use the data bus in 
the decode pipeline phase. As a consequence, section IV 
provides a more detailed study of the consequences of this 
fault injection in two cases: one case to highlight a fault on 
the instruction bus, another one to highlight a fault on the 
data bus. On the one hand, we study the effects on a generic 
single instruction. On the other hand, we study the specific 
case of a load instruction from the Flash memory. 

IV. Experiments on the data and instruction bus 

The two following subsections detail the results we ob- 
tained when trying to inject faults into the control flow or 
the data flow of the target program. In order to minimize the 
side effects which may happen when studying a big number 
of assembly instructions, the following results have been 
obtained for two classes of test applications. To highlight 
faults on the control flow, we use a sequence of NOP 
instructions [26]. Since NOP instructions have no effect, a 
faulty output will be easier to notice and to explain. To 
highlight faults on the data flow, the test application we use 
is a single LDR instruction which loads data from memory 
into a register. The initial values at the beginning of our 
target function are detailed in Table IV. Those beginning 
values are the same for the two following experiments. The 
comparison between the initial values, the output ones and 
the expected ones helps us to have a better understanding of 
possible instruction replacements effects. 

Table IV: Initial values at the beginning of the execution 



Piece of data 


Value 


r0 


A memory address in RAM 


rl to r4 


0x1 to 0x4 


r5 and r6 


Not relevant 


rl 


0x100 


r8 to rl2 


0x00 


Address pointed by rO 


0x00 



A. Faults on the program flow 

Faults on the program flow can be observed through 
instruction replacement faults thanks to the simulation. How- 
ever, studying instruction replacement with two possible 
instruction sizes is a very tough task. Since every fetch from 
the code memory is 32-bit wide, we need to consider several 
instruction replacement scenarios. With this approach, we 
can simulate the replacement of a 16-bit or 32-bit instruction 
by another 16-bit or 32-bit instruction. However, two 16- 
bit instructions might be replaced by two different 16-bit 
instructions. Similarly, a 32-bit instruction might be replaced 
by two 16-bit instructions. Those two cases would imply 
performing an almost-exhaustive search over 32 bits, which 
is not practical in our case. Though, we could partially 
bypass this problem by recording the number of clock 
cycles in our experiments. However, guessing the number of 



executed instructions from the clock cycle count is not an 
easy task because of the complex instruction set. Observing 
this clock cycle count could theoretically enable us to 
exclude some replacement scenarios in further experiments. 
To highlight the possibility to inject faults on the program 
flow, the following experiment targeted a NOP sled. Since 
different position probes and different injection times lead 
to different results, the following results have been found for 
different experimental configurations of these parameters. 

1) Hardware exceptions: Our fault injection some- 
times led to an exception triggering. However, only 
Usage Fault exceptions were observed. More precisely, 
the No coprocessor exception and the Undefined 
instruction exception where the only subclasses of 
Usage Fault which could be observed. Both of these 
exceptions happen in the case of an invalid opcode. A 
possible explanation would be that a fault has been injected 
during the fetch or decode pipeline phases. 

2) Memory address: In the initial state before the target 
instruction, rO points to a memory address in SRAM. The 
value of rO has been observed at this address instead of the 
expected value. For this particular case, instruction replace- 
ment simulation showed that the only possible instruction 
replacement is STR rO, [rO, #0] , which stores the value 
of rO at the address pointed by rO without any offset. 
Moreover, the value 0x10 0 has also been observed for 
another configuration. It turns out that 0x10 0 is also the 
value in r7. 

3) Other faults: We also obtained faults on the general- 
purpose register r7 and the program counter rl5. These 
faults can also be explained by at least one assembly 
instruction replacement. 

4) Summary: Obviously, the previous paragraphs do not 
aim at providing a complete list of the possible faults. 
Because of the huge number of possible configurations 
for the injection parameters, computing fault occurrence 
percentages would not be relevant. Nevertheless, these para- 
graphs highlight the fact that very few fault patterns were 
observed. We never got any fault on rl-r6 and r8-rl4. 
In an informal way, faults on r7 and rl5 (pc) appeared 
much more often than faults on the memory address pointed 
by rO. Most of the 16-bit instructions can only manipulate 
the registers rO to r7. For example, a MOVS r7, #FF 
operation is assembled into a 16-bit instruction, while a 
MOVS r8, #FF is assembled into a 32-bit instruction. In a 
16-bit instruction, r7 is encoded by a 111 binary sequence. 
The fact that registers r0-r6 are encoded with a smaller 
number of 1 in their encoding slot might explain this higher 
fault occurrence rate on the r7 register. Similarly, branch 
instructions have many 1 in their slot. As a conclusion for 
this set of experiments, every faulty result we observed has 
at least one instruction replacement which can explain it. 
The first intuition of a set at 1 fault model we saw for data 
fetches leads us to a more detailed analysis of the pipeline 



stages in section V. 

B. Faults on the data flow 

For this experiment, we targeted a single LDR 
r4, [ P C , # 4 4 ] instruction. The inital value of R4 was 0x0 
and PC+44 was a Flash memory address which contained 
0x12345678 (this experiment used the same configuration 
as the one we had defined in III-B3). We obtained several 
faulty outputs such as 0xFE345678 or 0xFFF45678. We 
consider that every fault which cannot be explained by an 
instruction replacement is a fault on the data flow. In this 
experiment, the target LDR r 4, [PC, #4 4] is a 16-bit in- 
struction, followed by a 16-bit NOP instruction. The Thumb2 
instruction set can only output a limited set of constants 
in a single data-processing instruction [24]. Thus, some of 
the faulty output values we observe, such as 0xFFF45678, 
could theoretically only be loaded with a single load from 
indirect register. Since the whole memory does not contain 
any FFF4 pattern, a single load instruction could not explain 
this result. We performed an exhaustive search over the 
16-bit and 32-bit instructions. No single instruction can 
lead to a result of 0xFFF45678. However, fault injection 
might have had an impact on two 16-bit instructions. To 
handle this issue, we performed another experiment, in 
which the target instruction was a LDR r8, [PC, #44], 
with 0x12345678 stored at the address PC+44. Using r8 
instead of r4 makes this instruction be assembled as a 32-bit 
instruction. Except the stack manipulation instructions, no 
16-bit instruction can write a value into registers between 
r8 and rl2. For this new configuration, we were able 
to obtain several faulty values, such as 0xFFF45679 or 
0xFFFC5679. With an exhaustive simulation, we can now 
guarantee that no single instruction can lead to such a result. 
Since a part of the faulty value is similar to the expected 
one, we can assume this fault injection had an impact on 
the data flow. 

C. Analysis at a lower abstraction level 

Underpowering a circuit or overclocking it leads to the 
same kind of timing violation faults [15], but knowing which 
among the clock tree or the power grid has been faulted is 
a tough task. To the best of our knowledge, recent research 
papers such as [27] claimed that the coupling between the 
injection probe and the circuit lies mainly in the power 
distribution network. According to the experiments from 
the previous section, electromagnetic glitch fault injection 
seems to enable us to perform attacks whose effect is 
equivalent to voltage or clock glitches, with a local effect 
that enables us to target either the instruction bus or the data 
bus. The following section deeply studies the bus transfers 
and provides an explanation for the faults we observed at a 
register-transfer level. 
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Figure 6: Bus transfers on the AHB bus for instruction memory 



V. Register-transfer level fault model 

The results presented in section IV lead us to the basics 
of a definition of a fault model at the assembly level. By 
using this fault injection technique, an attacker can inject 
faults in two ways: modify the instruction to be executed or 
modify a data value in the case of a load instruction. 

Our experiments also highlight another trend: we only 
managed to inject faults on data and instruction transfers 
from the Flash memory. The Flash memory has a slower 
reponse time than the SRAM memory. The fetch pipeline 
phase always requires a transfer from the instruction mem- 
ory [23]. The operand fetch operation is performed during 
the decode phase. For load instructions, the decode phase 
requires a transfer from the data memory. 

The microcontroller we use is based on a modified Har- 
vard architecture, with separate buses for instruction and 
data. The buses are 32-bit wide and use the AMBA AHB- 
Lite structure [28]. Since electromagnetic glitch injection 
creates timing faults [17], we propose an explanation of 
the experimental faults we obtained based on a bus transfer 
analysis. 

A. Instruction fetches 

Fetching a piece of data or an instruction from the 
memory (either SRAM or Flash) requires at least two 
clock cycles. Fig 6 shows a chronogram of the AHB bus 
tranfers when executing the target program. In this case, 
the target program is a NOP sled. Since instruction fetches 
are 32-bit wide, two 16-bit NOP instructions are fetched 
at each execution of the fetch pipeline stage. In the case 
of instruction which do not require an operand fetch, the 
decode and execute pipeline stages require at most half a 
clock cycle. The fetch stage requires one clock cycle during 
which the instruction address is written on the HADDRI bus. 
It also requires an extra clock cycle in which 32 bits from 



the instruction memory are written on the HRDATAI bus 
[28]. In the event of a transfer from the SRAM memory, the 
values are written on the HRDATAI bus at the beginning of 
this extra clock cycle. Since the Flash memory has a longer 
response time, this value is written on the bus at the end of 
this clock cycle for a Flash transfer. In this situation, since 
electromagnetic fault injection leads to timing faults [17], 
the critical path appears to be this HRDATAI bus transfer. 

Table V: Binary encoding of NOP and STR rO, [rO, #0] 



Mnemonic 


Inst. 


Binary instruction 


Hamming w. 


NOP 


BFOO 


10111111 00000000 


7 


STR rO, [rO, #0] 


6000 


01100000 00000000 


2 



We now consider the result presented in IV-A, in which 
a NOP is replaced by a STR rO, [r0,#0]. The binary 
encodings for the NOP and STR rO, [ rO , #0 ] instructions 
are presented in Table V. As seen for an attack which 
targets the value loaded by a load instruction, it seems 
that the higher the stress we apply, the higher the fetched 
word's Hamming weight is. However, the situation seems 
different for instruction fetches. The fault models seems 
more complex than the set at 1 model we had seen for data 
fetches. 

The bus precharge values are not specified in the AHB bus 
intellectual property. They are chosen by the circuit's manu- 
facturer. For the microcontroller we use, the HRDATAI bus 
does not seem to be precharged at 1, since a NOP instruction 
with a Hamming weight of 7 has been replaced by another 
instruction whose Hamming weight is 2. Moreover, since 
there must be some skew on this bus, some metastability 
phenomena (as presented in III- A) also appear. Considering 
this single example, a possible precharge value would be 0, 
or the microcontroller might use a more complex precharge 
strategy. For the moment, we are not able to infer more 
details about a possible HRDATAI bus precharge. 
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Figure 7: Bus transfers on the AHB bus for data memory 



To sum up, in the case of a bus transfer from the Flash 
memory, the critical path that is faulted by an electromag- 
netic fault injection seems to be the HRDATAI bus transfer. 
Thus, this fault injection can target any instruction fetch 
from the Flash memory, which potentially makes this attack 
scenario very harmful. 

B. Data fetches 

The situation for data fetches is very similar to the one we 
describe for instruction fetches. Since electromagnetic fault 
injection has a local effect, it is possible to find a probe 
position where we only inject faults on the data bus and 
do not reach the instruction bus. For this attack scenario, 
the critical path seems to be the HRDATA bus transfer. Fig. 
7a shows data bus transfers in the case of a single LDR 
instruction (similar to the previous experiments) without 
fault injection. Fig. 7b shows the same bus transfers in the 
case of a fault injection. 



Metastability phenomena also appear for this fault injec- 
tion, but the global trend corresponds to a set at 1 fault 
model. This value depends on the microcontroller's bus 
precharge strategy, which is specific to each implementation. 
This trend enables us to define a more precise fault model 
for data fetches, in which the attacker can bring the loaded 
value closer to the value of the bus precharge. 

VI. Related works 

This section outlines some research papers that are related 
to the study we presented in this paper. These papers 
are grouped into three subcategories: electromagnetic fault 
injection techniques, fault models on microcontrollers and 
proposed contermeasures against a given fault model. 

1) Electromagnetic fault injection: In [17], Dehbaoui 
et al. do a practical fault injection on a software imple- 
mentation of the AES algorithm by using electromagnetic 
glitches. In [25], Carlier performs a study of the effects of 
electromagnetic fault injection on two microcontrollers at 



an electric level. His work mostly explains the influence of 
several parameters related to the coil. He also studies the 
influence of the injection time. However, his study does not 
focus on the faults that were produced. 

2) Fault models on microcontrollers: In [29], Barenghi 
et al. study the effects on low-voltage fault attacks on 
an ARM9 microprocessor. They describe several effects 
on loads from memory or on instruction replacement. In 
[13], Balasch et al. present a black-box approach which 
is quite similar to the one proposed in this paper. They 
use clock glitches as a fault injection mean and perform 
their experiment on a 8-bit microcontroller. We also use 
the same kind of in-depth analysis. However, their study 
is performed on a very different architecture with a dif- 
ferent bus precharge configuration. We also automated the 
instruction replacement search by performing an exhaustive 
instruction replacement simulation over the instruction set. 
In [26], Spruyt proposes an approach whose aim is to 
define a generic method on how to build a fault model for 
microcontrollers. His situation is also quite similar to the 
one presented in this paper. Since having access to some 
internal data on a real microcontroller may be hard, he 
proposes a way to obtain information about the induced 
faults by analyzing the faulty outputs of different groups of 
instructions. Several articles have been published in which 
the authors assume an attacker can skip or replace an 
instruction by another one [18] [30]. For example, in [31], 
Berzati et al suppose an attacker can replace an addition 
instruction by an exclusive or instruction. 

3) Countermeasures: Several countermeasures schemes 
have been defined to protect embedded processor architec- 
tures against specific fault models. All those countermeasure 
schemes might be reinforced by studies similar to the one 
presented in this paper, which could provide a more precise 
knowledge about the fault model. At a hardware level, [32] 
proposes to use integrity checks to ensure that no instruc- 
tion replacement took place. Nevertheless, many counter- 
measures to protect assembly code without modifying the 
microcontroller's architecture have been defined. In [21], 
Barenghi et al. propose three countermeasure schemes based 
on instruction duplication, instruction triplication and parity 
checking. Their countermeasures enable different levels of 
fault detection and correction against instruction skips or 
some instruction modifications. In [33], Medwed et al. 
propose a generic approach based on the use of specific 
algebraic structures named AN+B codes. Their approach 
enables to protect both the control and data flow. An 
application to an AES implementation has also been detailed 
in [34]. 

VII. Conclusion 

We have presented a detailed study about the effects of an 
electromagnetic glitch fault injection on a state-of-the-art mi- 
crocontroller. However, working with a real microcontroller 



in a black-box approach creates several constraints when 
trying to build a practical experimental process. Because 
of the lack of details about the microcontroller's design 
and architecture, we have proposed this top-down approach 
which aims at building a suitable lower-level explanation for 
the faults we observed at an assembly level. Moreover, we 
also lack information about the bus precharge strategy on 
the microcontroller we use. Future experiments will try to 
use more advanced debug techniques in order to get more 
accurate information about the executed instructions. 

Finally, we do not claim this register-transfer level hy- 
pothesis is the only reason why faults appear at an assembly 
level. This paper aims at providing a first understanding of 
the faults an electromagnetic glitch fault injection can induce 
on an embedded program. And the lower-level model we 
propose could explain all the previous experimental results 
we obtained. Furthermore, this fault model looks very simi- 
lar to the ones which can be found in previous works about 
clock or voltage glitches. Hence, electromagnetic glitches 
seem to induce timing constraints violations on the bus 
transfers from the Flash memory. Thus, on a standard circuit, 
electromagnetic fault injection could enable an attacker to 
bypass some countermeasures against traditional timing fault 
injection means such as clock or voltage glitches. 

These experiments confirm the fact that an attacker could 
change an instruction into another one and change the value 
of a piece of data loaded from the Flash memory. But they 
also provide a more accurate fault model, in which some 
instructions or registers seem to be more vulnerable than 
others. On this architecture, faults on the data flow lead 
to an increased Hamming weight on the loaded piece of 
data. This behaviour highly depends on the microcontroller's 
bus precharge strategy. These observations can lead to the 
definition of an assembly-level fault model, and enable to 
build more specific and accurate countermeasures. These 
ideas will be studied more precisely in future works. 
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